    (Patent document 1) Patent National Publication 2001-519607 or WO99/18515 (Intel Corporation, USA): Method and device for translating a static identifier to a dynamically assigned network address    (Patent document 2) Patent Kokai 2002-135301 (NTT): IP address information notification method, IP address information notification device, and storage media storing this program    (Patent document 3) Patent Kokai 2002-318737 (Index): Management server    (Patent document 4) Patent Kokai 2002-281032 (Toshiba): Monitoring target switching program/method, and monitoring system    (Patent document 5) Patent Kokai H7-200502 (Omron): Redundant device for transaction processing system
The Internet consists of many computers and many networks of computers (“network” hereafter). These computers are interconnected on a global scale via communication links using TCP/IP protocols. The interconnected computers exchange information using various services such as e-mail, Gopher, and the World Wide Web (WWW).
A host on the Internet is identified using a unique IP address assigned by an organization tasked with assigning network addresses. The IP address is represented as fixed-length numbers for easy processing by computers; the long numeric IP address is difficult for people to remember without making input errors. An IP address is needed at a minimum to identify a host on a TCP/IP network but identifying a host using a numeric IP address is difficult for people; to solve this problem, hosts are identified using the domain name system (“DNS” hereafter).
DNS is not based on numbers like the IP address; instead it uses a meaningful character string supplied by a database system to identify hosts on the Internet. DNS configures hierarchical name spaces where a character string called domain name is registered and a host on the Internet is identified by associating the domain name with an IP address. This is called forward name resolution. Meanwhile, searching for a domain name from the IP address is called reverse name resolution. A feature of DNS is a tree-structured distributed database with the root server placed at the top. The IP address is subjected to routing restrictions (the IP address is position information in the IP address system), but a name in DNS can exist irrespective of the position of the host on a network.
Generally, each user organization connected to the Internet permanently and assigned IP addresses registers domain names via a domain name registration organization which operates the domain names for the user organization. The domain operation server is called a DNS server. To register a DNS server, an IP address and a host name are specified via the domain name registration organization.
The root server transfers domain operation authority to the first-level DNS server, which in turn transfers domain operation authority to the second-level DNS server, and finally the DNS server at the immediately preceding level transfers domain operation authority to the DNS server for the said user organization assigned IP addresses. FIG. 17 shows the DNS search sequence. The DNS server for each user-organization-assigned IP address performs actual setting, such as association of host name and IP address with domain name and specification of the mail routing.
With a conventional DNS, the setting file is set and updated manually. However, it has recently become difficult to statically associate a single host name and a single IP address with each other, because the IP addresses of PCs on in-house LANs change each time Windows (registered trademark) is restarted, due to popularization of the dynamic host configuration protocol (DHCP). Dynamic DNS provides a mechanism by which the DNS server's records are updated automatically by an update request from a client. The practicality of dynamic DNS is presently being verified both in networks not directly connected to the Internet, such as in-house LANs, but also in the Internet's global services.
When dynamic DNS is used in the Internet's global services, it is possible to provide Internet services at a (dial-up) host not assigned a network by the network assignment organization or not assigned a permanent assigned IP address by a provider.
Conventionally, dial-up connection involves the act of making a call to connect to the Internet, but recently, the dial-up connection does not necessarily require making a call because of widespread use of access lines (such as cable TV, digital subscriber lines, optical fibers, satellite links) using a fixed IP connection called permanent connection. This means that accounting based on connected hours is no longer prevalent. However, permanent connection is different from connection using leased lines because the IP address may change when reconnecting after the connection is disconnected due to faults such as router power failure, line fault, etc., or maintenance, or line disconnection by provider or timeout at dial-up host. Also, the IP address may change when a mobile terminal moves (handover) through wireless base stations. For convenience, this is also called dial-up because the terminal IP address changes.
By comparing connection made by assignment of a permanent network by a network-assignment organization (typically using conventional leased lines) with connection made by assignment of a permanent IP address by a provider (or by each user organization assigned IP addresses), the present invention calls making a connection by being assigned a
IP address by a provider (or by each user-organization-assigned IP address) (including connection made via DHCP or PPPoE not involving calling through a modem) a “dial-up connection”. The assignment of a transient IP address is called “perform transient connection” and the transient IP address assignment itself is called “dial-up”.
The DNS server (such as 4500 or 5500) stores queried resource records locally for some period. This storage is called cache. The resource record in cache is only stored for the specified TTL (time to live) period and is discarded when this period has elapsed. This period is called the cache TTL. During the cache TTL, the DNS server (such as 4500 or 5500) performs name resolution in response to queries from the resolver (such as 4100 or 4200, or 5300) by referencing the local cache storage. This cache method was devised to improve efficiency by suppressing repeated name queries. However, D (1000) suffers from an inadequacy, because the cache cannot follow changes in the IP address of T (4100) as explained below.
FIG. 16 shows how DNS is searched for from S-2 (5300) to reach the target host, T (4100).    (1): A forward name query for T (4100) is performed from S-2 (5300) to P-2 DNS (“P-2-D” hereafter) (5500).    (2): First, P-2-D (5500) checks whether it “knows” the target domain name; if it does, it immediately returns the IP address of T (4100)—the target host—to S-2 (5300). When P-2-D (5500) “knows” the target domain name, there are cases in which name is being managed by P-2-D (5500) and the IP address of T (4100), the target host, is cached in P-2-D (5500). FIG. 17 shows the case when P-2-D (5500) does not “know” the target domain name.    (3): In step (2) above, S-2 (5300) could determine the IP address of T (4100). S-2 (5300) accesses T (4100) using this IP address.
FIG. 17 shows the DNS search sequence when P-2-D (5500) is not managing the domain for T (4100) and when P-2-D (5500) has no IP address cache (at first name query) (step (2) in FIG. 16).    (1): A forward name query for T (4100) is performed from S-2 (5300) to P-2-D (5500).    (2): P-2-D (5500) performs a name query to the root DNS when it is not managing the domain for T (4100)—the target domain name—and also cannot find the IP address in cache.    (3): The root DNS returns the location of the JP DNS, for example, when the domain name of T (4100) is a JP domain. (If the domain name of T (4100) is not a JP domain, the root DNS returns the location of a name server managing ccTLD or gTLD to P-2-D (5500).)    (4): P-2-D (5500) performs a name query for the domain name of T (4100)—the target domain name—to the JP domain DNS obtained in step (3) above.    (5): The JP domain DNS returns the location of the server (here D (1000)) managing the domain name of T (4100)—the target host—to P-2-D (5500). (The said location is returned immediately because domains under JP are tree-structure registered at JPNIC and member servers, and are not divided for second-level DNS.)    (6): P-2-D (5500) performs a forward name query for the IP address to D (1000) obtained in step (5), using the name of T (4100) as the key.    (7): D (1000) returns the location of T (4100) to P-2-D (5500).    (8): P-2-D (5500) returns the location of T (4100) obtained in step (7) to S-2 (5300).    (9): S-2 (5300) accesses T (4100).
FIG. 18. Setting is generally performed so that the DNS (such as 4500 or 5500) is cached by the first name query, and then when the cache TTL has elapsed, the cache is invalidated. The correct IP address of T (4100) is obtained when the cache is invalid (FIG. 17) and name query is performed to D (1000). However, when the IP address of T (4100) changes while the cache is valid (FIG. 16), the IP address cached without performing name query to D (1000) is returned. In other words, the returned IP address (cached) is the address before the update shown in FIG. 18 is performed (172.16.100.100). As described in step (2) in FIG. 16, no cache problem occurs when P-2-D (5500) connected to S-2 (5300) is operating the T (4100) domain.
FIG. 11. Consequently, seen from the Internet, T′ (4200) can be misidentified as T (4100) when the cache is referenced.
Also at this time, even when T (4100) is a host with mail or www server functions, T′ (4200) is a host in which no mail server or www server is set (or even if T′ (4200) is a host in which it is set), the setting for T′ (4200) is different from that for T (4100), so T (4100) seems abnormal state (failure state).
FIG. 12. This problem is solved when the DNS server (such as 4500 or 5500) of each provider on the Internet performs name query to D (1000) again when the cache TTL has elapsed. Consequently, a normal state occurs as time passes as shown in FIG. 12.
Next, FIGS. 1-5 and FIGS. 13-14 show the case when T (4100) does not reconnect (remains disconnected). As with the normal case, it returns to the normal state over time (FIGS. 1-12).
Possible reasons for this problem include line or program failure (performing transient connection or dynamic DNS update).
Explanation given in FIGS. 1-5 are the same as the one given earlier. (Skip FIGS. 6-12 as explanation given in them is on cache problem.)
FIG. 13: At this time, T (4100) is not connected to the Internet, so P (4000) assigns the IP address (for example, 172.16.100.100 ) that has been assigned to T (4100) until an IP address change has occurred, to T′ (4200) when T′ (4200) performs transient connection.
FIG. 14. Update cannot be performed for the IP address of T (4100) set to D (1000), so the IP address (for example, 172.16.100.100) of T (4100) before T (4100) was disconnected remains set. Consequently, in this case, T′ (4200) is also misidentified as T (4100).
Incidentally, line disconnection is a detectable event at T (4100) and, at the same time, is also a change in the external environment.
Table 01 below shows the patterns of failure that occurs at T (4100) from relationship between its state and its assigned IP address.
TABLE 01State of IP addressIP address beforeline disconnection =IP address afterIP address before line disconnection ≠reconnectionIP address after reconnectionIP address assignedWhen no hostsWhen another hostto T before lineusing IP address assigned to Tusing IP address assigned to TdisconnectionState of T (4100)before line disconnectionbefore line disconnectionre-assigned to TLine remains disconnected (pattern 1)Not accessibleMisidentification—(FIG. 14)Failure to perform dynamic update to DNSNot accessibleMisidentificationOK(pattern 2)Reconnection after line disconnection (pattern 3)Within cache TTLOKNo cashing performedOKOK (FIG. 12)
Pattern 1 shows when the line remains disconnected. When T (4100) cannot make reconnection after line disconnection, misidentification occurs when the IP address assigned to T (4100) before line disconnection occurs is assigned to T′ (4200). When the IP address is not assigned to any host, T (4100) is not accessible. Not accessible means the state in which T (4100)—the target host—is lost sight of and cannot be reached. When line remains disconnected, T (4100) naturally cannot perform re-update to DNS servers (such as 4500 or 5500).
Pattern 2 shows the failure to perform dynamic update to DNS caused by program failure for dynamic update to T (4100) or by failure at D (1000). In this case, the line is either assumed to be connected, or to be reconnected if disconnected. In pattern 2, misidentification occurs when the IP address assigned to T (4100) before line disconnection is assigned to T′ (4200) as with pattern 1, in which T (4100) cannot make reconnection after line disconnection and remains disconnected.) T (4100) is not accessible when the IP address is not assigned to any host. When the assigned IP address does not change, there is no problem with communication from S-2 (5300), so T (4100) seems to be in the normal state.
Pattern 3 shows the case when the line is reconnected after being disconnected. The shaded part is affected by the cache TTL; other parts show the case when name query is performed correctly because caching is not performed. S-2 (5300) accessing T (4100) is a general Internet user. Whether or not a case is included in the shaded part depends on whether or not S-2 (5300) has previously performed name referencing, and if so, whether or not it was performed while caching is being performed.
The shaded part in Table 01 shows that although T (4100) operates correctly (T (4100) reconnects after line disconnection, and updating to D (1000) is performed correctly), T (4100) seems to be in a temporary failure state because a DNS server (such as 4500 or 5500) is caching the IP address of T (4100).
The above explanation shows that D (1000) has an inadequacy where the cache mechanism cannot follow changes in the IP address of T (4100).
This occurs because the dynamic DNS mechanism is an extension of conventional DNS.
As described earlier, conventional DNS was set and updated manually. The above explanation shows that when D (1000) is used and T (4100) performs updating to D (1000) at short intervals, sometimes the IP address of T (4100) obtained by performing (normal) referencing to D (1000) is incorrect.
S-2 (5300) always misidentifies T′ (4200) as T (4100) when T (4100) line disconnection intervals and T (4100) IP address update intervals are too short compared to the timing of name query to D (1000) after the cache TTL is exceeded. In such a case, which can also be caused by an unstable line, DNS should function, but D (1000) cannot function in this case, causing what appears to be a failure state. This problem is a DNS problem for the entire Internet that cannot be solved by individual implementations (at individual hosts).
Actual Example of Cache Problem
An actual example of a cache problem is explained below.
FIGS. 19-21 show an actual example in which the T (4100) IP address obtained by referencing the cached DNS (measurement made at 4500) during the cache TTL and the T (4100) IP address obtained by performing forward name resolution directly to D (1000) are different.
FIG. 19 shows the program used at actual measurement. The program is a UNIX shell script. The arrow (→) at the line end indicates that the line is returned for only display convenience; the actual line continues.
FIGS. 20-21 show the measurement results. At each trial, the first line indicates trial number, the second line indicates trial time, the third line indicates the T (4100) IP address (a, c, e) extracted by performing string processing for the result obtained by referencing D (1000) using the dig command of the ISC BIND, which is standard implementation for DNS, and the fourth to sixth lines indicate the T (4100) IP address (b, d, f) obtained by referencing the P DNS server, cached DNS (“P-D” hereafter) (4500) using the ping command. (Note: P-D (4500) is the DNS server usually referenced by T (4100). Here, the test is conducted at T (4100), so P-D (4500) is referenced, but when conducting the test at S-2 (5300), P-2-D (5500) should be referenced. The DNS referenced at each terminal is determined by the resolver.) The seventh to tenth lines indicate the ping command incidental output.
The DNS server D (1000) used in the trial is DynDNS.org, which already hosts dynamic DNS. At the trial, the server cache TTL is 1 minute, a quite short time.
An update request is sent from T (4100) concurrent with the first trial, and the update is completed between the first and second trials. Consequently, from the second trial, the dig command's output (T (4100) IP address indicated by D (1000)) and the ping command's output (P-D (4500) is referenced at this test but P-D (4500) is affected by the cache TTL) indicate different IP address respectively (“underlined part a=underlined part b” is changed to “underlined part c≠underlined part d”).
This problem is solved (“underlined part e=underlined part f”) at trial 16 performed just 1 minute after the second trial.
As described, cache TTL affects the referenced DNS server, causing address disagreement. However, the problem is solved as times passes. The cache TTL at D (1000) is short (1 minute), but address disagreement occurs nevertheless.
Common Misunderstanding
This problem is unique to dynamic DNS, but is generally not well known and even some patent applications contain misunderstandings.
For example, paragraph 0047 in patent document 3 says “reply to nslookup becomes abnormal.”
However, this is not true for two reasons: 1. because the reply to nslookup is not an error. (Patent document 3 shows no grounds for being able to determine that the reply is abnormal although it is not an error.) 2, the data that DNS returns in response to the nslookup query is the final updated IP address even if it is assumed that T (4100) is lost (or that the data is being used by T′ (4200)). (The IP address may be a cached address or depend on the queried DNS server. Either case is a problem.) In this case, it cannot be simply determined that the reply is abnormal; such a determination requires application-wise comparative judgment. In other words, to detect that the IP address returned by DNS is abnormal, reachability confirmation must be performed to determine whether the IP address pointed at by DNS is used by T (4100) itself or by a host other than T (4100), such as by T′ (4200).
The same applies to the case when explicit offline processing is performed by T (4100). This case has the effect of causing T′ (4200) to not appear. However, because the nslookup reply is not an error, this case requires application-wise comparative judgment about the set IP address. Also, note that generally no offline processing is performed at failure (including line failure) at T (4100).
Assuming that S-2 (5300) or management server (S-1 hereafter) (2000) stores the previous IP address of T (4100), the IP address is known to be updated by comparing the previous IP address and the IP address returned as the nslookup reply. However, it cannot be determined whether or not the updated IP address reflects the current state for the reason described in reason 2. In other words, this case is also affected by the cache problem; when T (4100) cannot perform update processing for D (1000) (for example, when line disconnection continues or a failure occurs in the update program), the value returned by D (1000) as the IP address of T (4100) is unreliable. In other words, an IP address no longer used by T (4100) might be returned.
However, patent document 3 also seems to state that T (4100) itself compares the reply to nslookup with the IP address of the own host (T (4100) (distribution server 3 in patent document 3). In this case, it is possible to determine that the nslookup reply is abnormal, because T (4100) simply compares the own host IP address and the nslookup result. (However, this compare operation is only possible for connection configurations 1 to 3 described later). However, hosts other than distribution server 3 cannot determine whether or not the reply is abnormal. In other words, only distribution server 3 can determine this. However, it is obvious that T (4100) corresponding to distribution server 3 can determine its own IP address. The object of the present invention is to make it possible for S-2 (5300) to confirm whether the originator reaches T (4100) correctly.
It is considered better for distribution server 3 to send an IP address update request to the dynamic DNS server using a change in the IP address assigned to itself as a trigger, than to perform nslookup.
Moreover, paragraph 0048 in patent document 3 says “for example, the reply to ICMP (Internet Control Message Protocol) is lost”. However, the reply cannot be said to be lost; in this case, the reply is undefined. ICMP is considered to be an ICMP echo request. It is derived from the command implementation, usually called ping.
Timing Problem:
When, for example, P (4000) receives a connection request from a host other than T (4100) immediately after T (4100) enters the line disconnection state, there is a high probability that the IP address assigned to T (4100) until just before is assigned to that terminal. Then, T′ (4200) appears and the ping command shows that T (4100) is alive. Consequently, a reply may be returned.
For example, when the trial count is 2 (FIG. 20 shows an example of the cache problem) note that the values c and d in FIG. 20 are different.
During the time from trial count 1 and trial count 2, T (4100) changes from the normal state shown in FIG. 4 to the disconnection state shown in FIG. 5 and then makes reconnection to go into the state shown in FIG. 8. When the another user shown in FIG. 9 dials up, T′ (4200) appears, because T (4100) is switched to T′ (4200) and forward name resolution to the DNS server shows no change in IP address. Naturally, “a ping reply is returned” from T′ (4200). If the timing matches, a ping reply will be passed continuously to T′ (4200).
Moreover, “a ping reply is returned” does not mean that T (4100) (distribution server 3 in patent document 3) is in a normal state. In this case, since DNS is updated when T (4100) returns to the normal state, the problem is soon solved, even considering the cache problem. However, the biggest problem is that T (4100) remains in the state shown in FIG. 5, and cannot change to the states shown in FIG. 6 or later (meaning that a failure occurs). Unlike the cache problem, once T′ (4200) of another users appears, (FIGS. 13 and 14), T (4100) continues to appear to be in the normal state, receiving the ping reply from T′ (4200).
Therefore, even if it is assumed that the size of a moving object shot by a video camera is recognized, machine cannot identify whether the object is a dog, a child, or a ball. But the human viewer can identify the image (the moving object) as soon as he/she. Similarly, nslookup or ping cannot solve this problem, and the state is regarded as normal (patent document 3 says this state is abnormal).
Specifically, if a webpage for Mr. B is displayed when someone visits the webpage for Mr. A, the human viewer immediately recognizes this as an error, but the DNS servers and other machines cannot.
Consequently, without confirming reachablity, machines cannot distinguich between T(4100) having correct reachability and T′(4200) that is a host misidentified as T(4100).
Therefore, a host that is transiently assigned a dynamic IP address has a problem of appearing to be in the failure state even if the host is operating correctly, so identification of the other communication end (from where a call should originate), which seems to have been completed with the advent of dynamic DNS, is inadequate.
Summary of Problem Unique to Dynamic DNS
The problem peculiar to dynamic DNS are summarized here.
Summary 1. D (1000) continues announcing the final updated resource record even after T (4100) has ceased to be connected. If T (4100) performs explicit offline processing, D (1000) will never continue announcing information on T (4100) that does not exist. However, when T (4100) is faulty or the line is disconnected, it cannot perform offline processing.
Summary 2. When the IP address of T (4100) changes, misidentification occurs during the cache TTL.
Scope of Extended Related Art
We have discussed the inadequacy of dynamic DNS for discovering the destination terminal. However, a similar problem also occurs in systems other than dynamic DNS. Examples are described in patent document 1, patent document 2, and ENUM.
ENUM is an extension of dynamic DNS that maps the telephone number system in the conventional telephone network (PSTN) onto DNS.
Patent document 1 adds the concept of user location server, but can be considered to be similar to ENUM.
Patent document 2 proposes a specific mapping notification system for a static identifier and dynamic assigned address that locate hosts (DNS is not used).
As stated in said summary 1, since misidentification occurs because “D (1000) continues announcing the final updated resource record even after T (4100) is no longer connected”, patent documents 1 and 2 disclose a specific method to solve the problem. In patent document 1, the fact that a terminal is alive is notified by sending a keep-alive signal to DNS from the terminal. In patent document 2, a health check is performed from the equivalent of DNS to the equivalent of T to detect the state that the equivalent of T is not connected occurs.
In both cases, when a destination terminal is not on the network, the appropriate record in the mapping notification system is deleted so the originator terminal never discovers the destination terminal.
However, in both cases, the correctness of reachability from third-party terminal S to T (4100) is not verified (end-to-end accessibility is not verified).